SwiftUI: Rigid by Design

SwiftUI is a modern UI language. No one has ever really tried to dispute that—and if they have, they’ve come around. Why? Because the framework is built on top of the Swift's core, appealing features, mainly result builders. SwiftUI is currently three years old, and it has made declarative UI programming on Apple’s platforms a native reality. Yet, the framework continues to be stubborn, making the developer experience with the language challenging.

Say you have the dream to make the perfect calculator app. This app will have many functions and be organized in a form just like the system Settings app. In this case, SwiftUI is your best friend and helpful parter. The project is super simple to quickly flesh out and the code not only looks nice, but will be easy to understand and maintain in the future. Moreover, as the framework improves over time, the app will continue to get better with smoother animations, transitions, and run faster too.

Not everyone likes just a plain, bland form-based app, though. I certainly don't. So let's say, you want to do a slight bit of customization to the UI, say change the colour of the navigation title or background colour of the form — You can't. SwiftUI stubbornly tells you no, use UIKit instead; Actually, it doesn’t tell you. It just hopes you have the smarts enough to realize this behaviour isn’t possible using the framework.

I recently ran across this exact situation. I didn’t want the main screen of my app to look like many others. I wanted to add a custom background as well as overlayed components. If I didn't, my app wouldn't stand out and would look like so many others out on the App Store. However, I couldn’t use the standard List view, because it prevents you from changing the background. To get the simple behaviour I desired, I had to create my own entire UIKit implementation of the list. This allowed me to achieve my desired outcome, but at what technical debt and cost? In terms of line count, my custom implementation took over 15x more code than the integrated SwiftUI layout.

It may seem that I am using this example to nitpick the framework. I assure you, though, I have only introduced the smallest of issues regarding SwiftUI’s customization and flexibility. See, for instance, the difficulty in changing the colour of a picker.

The stubbornness of SwiftUI is by design; It add's simplicity, improves ease of use, and reduces the time spent developing the UI. Yet, despite its prophetic goals, the framework intentionally makes it more difficult for developers to design customized components and shape their user's experience. You can quickly mock-up a prototype layout, but only as long as you are well within the framework's boundaries.

I am very excited, happy, and overjoyed about this year’s WWDC22. Yet, the one thing I wish they would’ve done for SwiftUI this year is given us control over the framework's inner workings to allow for even a degree of personalization. With the introduction of a suite of tools for end users to customize their home screens, you would think the same might be reflected, even slightly, in Apple's poster child for developers.

Apple engineers use this framework more and more often (see the iOS 15 Weather app) to create UIs. They’ve run across the same problems as I have with SwiftUI. Yet, the difference is that the framework is built around their design conventions, making its lack of flexibility a nonissue for them.

SwiftUI is great, but it’s getting a bit lost. This framework is young and has lots of time to mature. I just hope it establishes itself more as the modern way of writing all apps, not just Apple’s apps.